Docker for Java Developers

The Docker Toolbox is an installer to quickly and easily install and setup a Docker environment on your computer. Available for both Windows and Mac, the Toolbox installs Docker Client, Machine, Compose, Kitematic and VirtualBox.

Install Git Client as explained at: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

You can find GIT for Windows at: http://classroom.example.com:8082/downloads/Git-2.6.2-64-bit.exe

Docker currently runs natively on Linux. It can be configured to run in a virtual machine on Mac or Windows. This is why Virtualbox is a requirement for Mac or Windows. Docker Toolbox already includes Virtualbox but if you are a Linux user and wants to simulate multiple nodes in a Docker cluster, you must install VirtualBox.

Docker Machine makes it really easy to create Docker hosts on your computer, on cloud providers and inside your own data center. It creates servers, installs Docker on them, then configures the Docker client to talk to them.

Use the following command on Windows:

And then execute all the set commands.

This will provide the IP address associated with the Docker Machine created earlier.

Docker Client is used to communicate with Docker Host.

Check if the client is working by executing:

Which will return an empty list of containers working. If you get an error message, make sure to have put the docker client into a folder that is contained in your path expression and that you executed the "docker-machine env lab" command according to your operatingsystem.

To install JBoss Developer Studio stand-alone, complete the following steps:

Follow the on-screen instructions to complete the installation process.

Machine makes it really easy to create Docker hosts on your computer, on cloud providers and inside your own data center. It creates servers, installs Docker on them, then configures the Docker client to talk to them.

Once your Docker host has been created, it then has a number of commands for managing containers:

You used Docker Machine already during the attendee setup. We won’t need it too much further on. But if you need to create hosts, it’s a very handy tool to know about. From now on we’re mostly going to use the docker client.

Find out more about the details at the Docker Machine Website.

Check if docker machine is working:

It shows the output similar to the one shown below:

The client communicates with the demon process on your host and let’s you work with images and containers.

Check if your client is working using the following command:

It shows the output similar to the following:

The most important options you’ll be using frequently are:

Get a full list of available commands with

A more comprehensive list of commands is also available in Common Docker Commands.

Check if your Docker Host is running:

You should see the output similar to:

This machine is shown in “Running” state. If the machine state is stopped, start it with:

After it is started you can find out IP address of your Docker Host with:

We already did this during the setup document, remember? So, this is a good chance to check, if you already added this IP to your hosts file.

Type:

and see if this resolves to the IP address that the docker-machine command printed out. You should see an output as:

If it does, you’re ready to start with the lab.

Let’s first check, if any images are available:

At first, this list is empty.

Now, let’s get a vanilla jboss/wildfly image:

By default, docker images are retrieved from Docker Hub. In our case, we’re providing a so called private registry via the instructor laptop.

You can see, that Docker is downloading the image with it’s different layers.

In our particular case, the jboss/wildfly image extends the jboss/base-jdk:8 image which adds the OpenJDK distribution on top of the jboss/base image. The base image is used for all JBoss community images. It provides a base layer that includes:

The “jboss/base-jdk:8” image adds:

When the download is done, you can list the images again and will see the following:

For now, all we did is pull the container description (aka image) down to our local laptops. Now we want to actually run an instance of the image as a so called "container".

Startup log of the server shows that the server is located in the /opt/jboss/wildfly. It also shows that the public interfaces are bound to the 0.0.0.0 address while the admin interfaces are bound just to localhost. This information will be useful to learn how to customize the server.

docker-machine ip <machine-name> gives us the Docker Host IP address and this was already added to the hosts file. So, we can give it another try by accessing: http://dockerhost:8080. However, this will not work either.

If you want containers to accept incoming connections, you will need to provide special options when invoking docker run. The container, we just started, can’t be accessed by our browser. We need to stop it again and restart with different options.

Restart the container as:

-P map any exposed ports inside the image to a random port on the Docker host. This can be verified as:

The port mapping is shown in the PORTS column. Access the WildFly server at http://dockerhost:32768. Make sure to use the correct port number as shown in your case.

Lets stop the previously running container as:

Restart the container as:

The format is -p hostPort:containerPort. This option maps container ports to host ports and allows other containers on our host to access them.

Now we’re ready to test http://dockerhost:8080 again. This works with the exposed port, as expected.

Lets stop the previously running container as:

Default WildFly image exposes only port 8080 and thus is not available for administration using either the CLI or Admin Console. Lets expose the ports in different ways.

Docker build images by reading instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. docker build command uses this file and executes all the commands in succession to create an image.

build command is also passed a context that is used during image creation. This context can be a path on your local filesystem or a URL to a Git repository.

Dockerfile is usually called Dockerfile. The complete list of commands that can be specified in this file are explained at https://docs.docker.com/reference/builder/. The common commands are listed below:

This image uses fedora as the base image. CMD command defines the command that needs to run. It provides a different entry point of /bin/echo and gives the argument “hello world”.

. in this command is the context for docker build.

to see the output:

and view the images as:

Docker images can be saved using save command to a .tar file:

These tar files can then be imported using load command:

We’re going to build the application first.

Create a folder to place the deployments and give it write access

Start WildFly server as:

This command starts a container named “wildfly”.

The -v flag maps a directory from the host into the container. This will be the directory to put the deployments. rw ensures that the Docker container can write to it.

Check logs to verify if the server has started.

Access http://dockerhost:8080 in your browser to make sure the instance is up and running.

Now you’re ready to deploy the application for the first time.

Start JBoss Developer Studio, if not already started.

Click on ‘Finish’.

The host name is specified to ‘dockerhost’. Two properties on the left are automatically propagated from the previous dialog. Additional two properties on the right side are required to disable to keep deployment scanners in sync with the server.

The project runs and displays the start page of the application.

Congratulations!

You’ve deployed your first application to WildFly running in a Docker container from JBoss Developer Studio.

Stop WildFly container when you’re done.

TThe Command Line Interface (CLI) is a tool for connecting to WildFly instances to manage all tasks from command line environment. Some of the tasks that you can do using the CLI are:

Lets use the CLI to deploy javaee7-simple-sample to WildFly running in the container.

Start WildFly server as:

This command starts a container named “wildfly-managed”.

This will show the output as:

Now you’ve sucessfully used the CLI to remote deploy the Java EE 7 sample application to WildFly running as docker container.

WildFly comes with a web-based administration console. It also relies on the same management APIs that are used by JBoss Developer Tools and the CLI. It provides a simple and easy to use web-based console to manage WildFly instance. For a Docker image, it needs to be explicitly enabled as explained in Enabling WildFly Administration. Once enabled, it can be accessed at http://dockerhost:9990.

Username and password credentials are shown in [WildFly_Administration_Credentials].

Deploy the application using the console with the following steps:

This will complete the deployment of the Java EE 7 application using Web Console. The output can be seen out http://dockerhost:8080/javaee7-simple-sample and looks like:

A standalone WildFly process, process can be configured to listen for remote management requests using its “native management interface”. The CLI tool that comes with the application server uses this interface, and user can develop custom clients that use it as well. By default, WildFly management interface listens on 127.0.0.1. When running inside a Docker container, the network interface should be bound to all publicly assigned addresses. This can be easily changed by biding to 0.0.0.0 instead of 127.0.0.1.

In addition to application port 8080, the administration port 9990 is exposed as well. The WildFly image that is used has tweaked the start script such that the management interface is bound to 0.0.0.0.

TODO Improve the explanation

You can scale the services up as:

Check the logs…​

Check the running instances:

You can also decide to reduce the number of running instances:

Stop the services as:

Stop the services as:

Kubernetes, or “k8s” in short, allows the user to provide declarative primitives for the desired state, for example “need 5 WildFly servers and 1 MySQL server running”. Kubernetes self-healing mechanisms, such as auto-restarting, re-scheduling, and replicating containers then ensure that this state is met. The user just define the state and Kubernetes ensures that the state is met at all times on the cluster.

How is it related to Docker?

Docker provides the lifecycle management of containers. A Docker image defines a build time representation of the runtime containers. There are commands to start, stop, restart, link, and perform other lifecycle methods on these containers. Kubernetes uses Docker to package, instantiate, and run containerized applications.

How does Kubernetes simplify containerized application deployment?

A typical application would have a cluster of containers across multiple hosts. For example, your web tier (for example Undertow) might run as a few instances, and likely on a set of containers. Similarly, your application tier (for example, WildFly) would run on a different set of containers. The web tier would need to delegate the request to application tier. The web, application, and database tier would generally run on a separate set of containers. These containers would need to talk to each other. Using any of the solutions mentioned above would require scripting to start the containers, and monitoring/bouncing if something goes down. Kubernetes does all of that for the user after the application state has been defined.

At a very high level, there are three key components:

A picture is always worth a thousand words and so this is a high-level logical block diagram for Kubernetes:

After the 50,000 feet view, lets fly a little lower at 30,000 feet and take a look at how Kubernetes make all of this happen. There are a few key components at Master and Node that make this happen.

Kubernetes cluster can be easily started using Vagrant. There are two options to start the cluster - first using a downloaded Kubernetes distribution bundle and second by downloading the latest bundle as part of the install.

Pods, and the IP addresses assigned to them, are ephemeral. If a pod dies then Kubernetes will recreate that pod because of its self-healing features, but it might recreate it on a different host. Even if it is on the same host, a different IP address could be assigned to it. And so any application cannot rely upon the IP address of the pod.

Kubernetes services is an abstraction which defines a logical set of pods. A service is typically back-ended by one or more physical pods (associated using labels), and it has a permanent IP address that can be used by other pods/applications. For example, WildFly pod can not directly connect to a MySQL pod but can connect to MySQL service. In essence, Kubernetes service offers clients an IP and port pair which, when accessed, redirects to the appropriate backends.

Any Service that a Pod wants to access must be created before the Pod itself, or else the environment variables will not be populated.

The order of Service and the targeted Pods does not matter. However Service needs to be started before any other Pods consuming the Service are started.

Kubernetes allow multiple resources to be specified in a single configuration file. This allows to create a “Kubernetes Application” that can consists of multiple resources easily.

Deploy Java EE Application (multiple configuration files) showed how to deploy the Java EE application using multiple configuration files. This application can be delpoyed using a single configuration file as well.

Notice that each section, one each for MySQL Pod, MySQL Service, and WildFly Replication Controller, is separated by ----.

Replication Controller ensures that specified number of pod “replicas” are running at any one time. If there are too many, the replication controller kills some pods. If there are too few, it starts more.

WildFly Replication Controller is already running with one Pod. Lets delete this Pod and see how a new Pod is automatically rescheduled.

Status of the Pods can be seen in another shell:

Notice how Pod with name “wildfly-rc-w2kk5” was deleted and a new Pod with the name “wildfly-rc-xz6wu” was created.

Replication Controller allows dynamic scaling up and down of Pods.

Notice a new Pod with the name “wildfly-rc-bymu7” is created.

Notice only one Pod is running now.

Logs can be obtained for any Kubernetes resources using this way. Alternatively, the logs can also be seen by logging into the node:

Default root password for VM images created by Vagrant is ‘vagrant’.

Individual resources (service, replication controller, or pod) can be deleted by using delete command instead of create command. Alternatively, all services and replication controllers can be deleted using a label as:

Default root password for VM images created by Vagrant is ‘vagrant’.

Depending upon the network speed and restrictions, you may not be able to download Docker images from Docker Hub. The error message may look like:

This section provide a couple of alternatives to solve this.

Double check, that you have the correct version of VirtualBox installed. Clear all host-adapter interfaces in Virtualbox before creating a new machine. Make sure to have git for windows in your path.

Are you not able to create Docker Machine on Windows?

Try starting a cmd with Administrator privileges and then give the command again.

Accessing the WildFly and MySQL sample in Kubernetes gives 404 when you give the command curl http://10.246.1.23:8080/employees/resources/employees/.

This may be resolved by stopping the node and restarting the cluster again:

These commands need to be given in the ‘kubernetes’ directory.

If you get the following error when creating a docker machine

Then you need to go to the boot2docker releases page on

https://github.com/boot2docker/boot2docker/releases

And download the latest .iso

After that you can move that iso to the docker cache directory. This is located in ~/.docker/machine/cache on Mac & Linux and /Users/yourUserName/.docker/machine/cache on Windows.

Issue: https://github.com/docker/machine/issues/2186 is raised so that the docker-machine team can hopefully find a way around this.